Vor über einem Jahrzehnt prägte Marc Andreessen mit seinem Statement „Software is eating the world“ die Digitalisierungsbewegung von Unternehmen [1]. Inzwischen haben zahlreiche Geschäftsfelder tiefgreifende Veränderungen erfahren und neue Geschäftsmodelle sind entstanden. Diese sind auf Organisationsstrukturen und IT-Systemarchitekturen angewiesen. Wenn das Geschäftsmodell wächst, müssen auch diese Strukturen mitwachsen und sich neu ausrichten. Wächst das Geschäftsmodell zu schnell, können organisatorische und technische Strukturen oft nur schwer Schritt halten. Das führt zu einem undurchsichtigen und unpassenden Geflecht aus kommunikativen, koordinativen, technischen und fachlichen Abhängigkeiten. Dieses Schicksal, das wir in Anlehnung an Marc Andreessen als „Dependencies are eating the business domain“ bezeichnen, führt dazu, dass die Businessdomäne nur noch langsam oder gar nicht mehr wachsen und sich verändern kann. Unser Lösungsvorschlag: ein Gamification-Ansatz mit Domain-Driven Design Cards und dem Context Mapping Game.

Strategisches Domain-Driven Design

Der strategische Teil des Domain-Driven Designs beinhaltet die Dekomposition der Businessdomäne in Subdomänen und Bounded Contexts. Mit Hilfe einer Context Map werden die Abhängigkeiten zwischen den Bounded Contexts visualisiert. Dabei werden die Abhängigkeiten mittels Context-Mapping-Patterns beschrieben. Letztere stellen eine Mustersprache dar, um Abhängigkeiten auf technischer, fachlicher und organisatorischer Ebene zu gestalten. Auf diese Weise wird eine soziotechnische Architektur der Businessdomäne definiert, die nicht nur den fachlichen Systemschnitt, sondern auch die Entwicklungsteams hinter den Bounded Contexts berücksichtigt [2].

Das Ziel des Domain-Driven Architect besteht darin, Bounded Context auf der strategischen Architekturebene sinnvoll und in den meisten Fällen möglichst unabhängig von anderen Bounded Contexts zu gestalten. Eine optimale Lösung ist nicht immer möglich. Die Transparenz hinsichtlich der Abhängigkeiten sowie deren methodische Betrachtung sind jedoch sehr nützlich. Es geht darum, die Vor- und Nachteile sorgfältig abzuwägen und bewusste Entscheidungen zu treffen. Die bewusste Gestaltung von Abhängigkeiten ist dabei nicht nur zu Beginn eines Projekts wichtig. Zu diesem Zeitpunkt ist oft das Wissen unvollständig und Weiterentwicklungen sind nicht vorhersehbar. Daher ist eine regelmäßige Überprüfung und Anpassung sinnvoll. In der Praxis wird dies aber selten durchgeführt.

Eine Untersuchung der Abhängigkeiten ist besonders dann relevant, wenn das System oder das Projekt aus dem Gleichgewicht gerät. Dies geschieht in der Regel aufgrund verschiedener Arten von Wachstum. Zwei Szenarien, die Anlass geben, die Abhängigkeiten in der strategischen Architektur neu zu überdenken, sind das Wachstum des Systems und das Wachstum des Geschäftsmodells [3] (siehe Kasten: „Wachstum und Folgen“).

Wachstum und Folgen

Wachstum des Systems

Das System wächst rasant und die Abhängigkeiten zwischen den internen Komponenten des Systems bauen sich stetig weiter auf. Zusätzlich werden immer mehr externe Systeme angebunden. Die Komplexität der Integration verknüpft sich mit der Herausforderung, unterschiedliche Domänen- und Kommunikationsmodelle zu handhaben. Wenn sich diese Modelle ändern, führt das zu Seiteneffekten und erfordert Anpassungen im System. Das System ist aufgrund der entstandenen Komplexität nur schwer erweiterbar.

Wachstum des Geschäftsmodells

Geschäftsmodelle und Organisationen wachsen, was über die Zeit Anpassungen in der IT-Architektur bedingt. Das ist besonders dann der Fall, wenn das Geschäftsmodell auf einem monolithischen System gewachsen ist. Die Skalierung von Teams bedeutet nun eine Zerlegung des Systems in Subsysteme zur Aufteilung auf mehrere Teams. Dadurch entstehen neue Abhängigkeiten und bereits bekannte Abhängigkeiten zu externen Systemen müssen neu gedacht werden.

SIE LIEBEN AGILE?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Businessdomäne, Bounded Context und Domänenmodell

Eine Businessdomäne ist der Bereich, in dem ein Unternehmen aktiv ist, am Markt teilnimmt und Kunden Produkte oder Dienstleistungen anbietet. Bounded Contexts sind das Mittel zur Zerlegung dieser Domäne in fachlich unabhängige Module der strategischen Architekturebene (Abb. 1). Ein Bounded Context ist ein fachlich abgrenzbarer Bereich, der gleichzeitig eine physische Grenze zu anderen Bounded Contexts darstellt. Er liegt in der Verantwortlichkeit eines Teams und wird unabhängig von anderen Bounded Contexts versioniert, weiterentwickelt und in Produktion gebracht.

Das Besondere an Domain-Driven Design und am Bounded Context ist, dass das Domänenmodell im Mittelpunkt steht. Durch dieses Modell werden Eigenschaften, Ereignisse und Funktionen der Businessdomäne zum Ausdruck gebracht. Als allgegenwärtige Sprache (Ubiquitous Language) dient das Domänenmodell als Bindeglied zwischen allen Projektphasen (Discover, Plan, Do, Check, Adjust), Architekturebenen (strategische, soziotechnische und taktische Architektur) sowie den beteiligten Personen (Architekt:in, Entwickler:in, Product Owner, Agile Coach, Tester:in, UX-Designer:in etc.).

Neben den bereits erwähnten Eigenschaften eines Bounded Context ist der entscheidende Punkt, dass er einen abgegrenzten Bereich (Bounded) um die Bedeutung eines fachlichen Modells (Context) darstellt. Domain-Driven Design formuliert die Heuristik, dass jeder Bounded Context sein eigenes Domänenmodell spezifisch und fachlich eindeutig realisieren sollte. Das Domänenmodell existiert folglich nur in diesem Bounded Context und hat dort Gültigkeit [2], [4]. Fowler [5] erklärt das anhand der Domänenobjekte „Kunde“ und „Produkt“ mittels der unterschiedlichen Perspektiven der Vertriebs- und Supporteinheiten auf diese Geschäftsobjekte. Fachliche Abhängigkeiten existieren in der Realität selbstverständlich trotzdem und müssen als Abhängigkeiten zwischen Bounded Contexts berücksichtigt werden. Das geschieht im Context Mapping.

Abb. 1: Dekomposition einer Businessdomäne in Subdomänen und Bounded Contexts

Abhängigkeiten zwischen Bounded Contexts gestalten

Wenn zwei Systeme miteinander kommunizieren müssen, ist die resultierende technische Abhängigkeit offensichtlich. Es gibt einen Konsumenten, der auf eine vom Provider angebotene Funktionalität zugreift. Auf der technischen Architekturebene kann sich diese Abhängigkeit vereinfacht wie folgt darstellen (Abb. 2):

1. Der Provider stellt eine Schnittstelle zur Verfügung, die von Konsumenten über eine Netzwerkschnittstelle (z. B. HTTP) oder als Bibliothek (z. B. JAR) genutzt werden kann.
2. Der Provider veröffentlicht über einen Broker ein Event. Darauf abonnierte Konsumenten empfangen dieses Event durch den Broker und können es weiterverarbeiten.

Abb. 2: Provider-Konsument-Beziehung zwischen Systemen

Oft wird die daraus resultierende fachliche Abhängigkeit zwischen den Systemen weniger bewusst betrachtet. Provider exponieren ihr Domänenmodell oder einen Teil davon über ihr API oder über Events nach außen. Ändert sich die Fachlichkeit des Providers, ändert sich auch sein Modell und in der Folge das exponierte Modell für die Konsumenten. Für sie stellt sich die Frage, inwieweit das externe Domänenmodell übernommen und in die eigene Domäne integriert werden sollte. Haben die Konsumenten das Ziel, schnell und mit minimalem Aufwand auf Veränderungen des Providers zu reagieren, müssen passende architektonische Lösungsstrategien angewendet werden. Ist das nicht nötig, beispielsweise aufgrund weniger hoher Anforderungen an die Reaktions- und Anpassungszeit oder wenn die Auswirkungen von Veränderungen beim Provider trotz tiefer Integration minimal sind, können einfachere Ansätze genutzt werden.

Im Context Mapping findet sich die fachliche Abhängigkeit als Model Flow wieder. In Abgrenzung dazu wird die technische Abhängigkeit als Call Flow bezeichnet. Der Influence Flow berücksichtigt, dass hinter Bounded Contexts potenziell unterschiedliche Entwicklungsteams stehen (Abb. 3).

Abb. 3: Darstellung des Model Flow, Call Flow und Influence Flow der Methode Context Mapping

Ist das der Fall, ergibt sich aus der technischen und fachlichen Abhängigkeit auch eine organisatorische Abhängigkeit zwischen diesen Teams. Domain-Driven Design untersucht dabei, wie stark diese Teams ihren gegenseitigen Erfolg beeinflussen. Je stärker die Abhängigkeit ist, desto größer ist der Einfluss [2], [6]. Auf organisatorischer Ebene spiegeln sich Abhängigkeiten mit negativer Tendenz wie folgt wider:

• Notwendigkeit einer abgestimmten oder gemeinschaftlichen Planung der fachlichen Roadmap mit regelmäßigen Zielkonflikten in der Priorisierung
• erschwerte, mehrdeutige und widersprüchliche Definition der Fachlichkeit
• Drang, Änderungen in den eigenen Systemen vorzunehmen, aufgrund nicht abgestimmter Änderungen beim Provider
• Drang, Features zu priorisieren, die vorwiegend auf die Ziele eines Konsumenten einzahlen

Bei der Betrachtung der Abhängigkeit zwischen zwei Bounded Contexts werden diese als Upstream- oder Downstream-Kontexte kategorisiert. Damit wird ausgedrückt, welcher Bounded Context weniger abhängig (Upstream) oder stärker abhängig (Downstream) vom anderen ist. Stehen Bounded Contexts in einer Upstream-Downstream-Beziehung, beeinflussen sie ihren Erfolg. Mit Hilfe von Context-Mapping-Patterns wird detaillierter ausgestaltet, wie stark sich die Abhängigkeit und die Beeinflussung des Erfolgs in der Architektur und in der Organisation manifestieren [2]. Ein Team hat Erfolg, wenn es Sprintziele und Termine mit der geforderten Funktionalität einhalten kann. Fehlerfreiheit in der Implementierung, Code- und Architekturqualität drücken ebenfalls den Erfolg eines Entwicklungsteam aus. Die fachliche Trennung mittels Bounded Contexts und die Beziehungsgestaltung mittels Context-Mapping-Patterns haben das Ziel, eine gute Basis für den Erfolg zu schaffen.

Die DDD Crew [6] beschreibt neun Context-Mapping-Patterns. An dieser Stelle werden drei Muster näher erläutert. Unterstützend ist dieser Sachverhalt in Abbildung 4 visualisiert.

Bietet ein Provider eine Schnittstelle mit exponiertem Domänenmodell an, ohne dass es durch Konsumenten beeinflusst werden kann, handelt es sich um einen Open Host Service. Ein Open Host Service kann von vielen Bounded Contexts in gleicher Weise genutzt werden.

Abb. 4: Darstellung des Zusammenwirkens der Context-Mapping-Patterns Open Host Service, Conformist und Anticorruption Layer

Wenn ein konsumierender Bounded Context das Domänenmodell akzeptiert und tief integriert, entsteht eine starke fachliche Abhängigkeit. Der Bounded Context wird dann als Conformist bezeichnet. Andererseits, wenn das exponierte Domänenmodell an der Grenze des konsumierenden Bounded Context transformiert wird, wird die Abhängigkeit auf einen Punkt, die transformierende Schicht, verlagert. Das wird durch das Muster Anticorruption Layer ausgedrückt. Ein Anticorruption Layer reduziert die Kopplung und befähigt den Konsumenten, schnell auf Veränderungen beim Provider zu reagieren. Der Open Host Service ist immer ein Upstream-Kontext, während der Conformist und der Anticorruption Layer Downstream-Kontexte darstellen [2], [6].

Die ganzheitliche Erstellung einer Context Map für eine Businessdomäne erfordert ein tiefes Verständnis aller Muster und eine intensive, analytische Auseinandersetzung mit den direkten und indirekten Beziehungsgeflechten zwischen allen Bounded Contexts. Das ist sicherlich eine Aufgabe, die Affinität und Expertise seitens der Ersteller:innen voraussetzt.

Gamification als Enabler für Context Mapping

Die Kernidee von Gamification besteht darin, Prinzipien und Elemente aus Spielen in andere Kontexte zu integrieren, um Motivation, Kreativität, Engagement und Interaktion von Menschen zu steigern. Ein Erfolgsfaktor ist die intrinsische Motivation sowie der natürliche Spieltrieb von Menschen, gewünschte Verhaltensweisen auszuführen, Aufgaben zu erledigen oder Ziele zu erreichen [7], [8]. Mit Fokus auf Domain-Driven Design Cards werden Spieler:innen als Team mit Herausforderungen konfrontiert, die sie gemeinsam meistern müssen. Dies geschieht in Form von Missionen, die im Spielverlauf abgeschlossen werden müssen. Gamification-Ansätze wie Domain-Driven Design Cards erfreuen sich in verschiedenen Bereichen der Organisations- und Softwareentwicklung großer Beliebtheit. So haben Domain-Driven Design Cards Inspiration in Backlog Refinement Cards [9], unFix Cards [10] oder Cards 42 [11] gefunden.

Ein weiterer wichtiger Aspekt von Domain-Driven Design Cards ist das Ziel, alle Mitglieder der Gruppe gleichwertig zu involvieren, unabhängig von ihrem Wissensstand und Charaktertyp. Das trägt zu den Zielen der Domain-Driven-Design-Philosophie bei, die eine Kultur des breiten gemeinsamen Verständnisses und der Zusammenarbeit anstrebt. Das Context Mapping Game der Domain-Driven Design Cards dient als Enabler für die soziotechnische Architektur mittels Context Mapping. Das Context Mapping Game basiert auf der Annahme, dass in der Realität selten eine Gruppe existiert, die durchgehend über tiefes Wissen im Bereich Domain-Driven Design oder in der Methode des Context Mapping verfügt. Daher ist die Zielsetzung des Context Mapping Game, dass es auch ohne diese Expertise spielbar ist.

Eine kurze Einführung im Vorfeld ist empfehlenswert, insbesondere wenn diese Methode für die Teilnehmer:innen völlig neu ist. Die Teilnahme am Spiel erfordert lediglich ein Grundverständnis der Idee von Context Mapping. Das Spiel ermöglicht die Zusammenarbeit zwischen Entwickler:innen, Architekt:innen, Product Ownern, Fachexpert:innen und Produktmanager:innen, da das Wissen über Abhängigkeiten in einer komplexen Businessdomäne auf viele Köpfe verteilt ist und für alle in gleicher Qualität transparent gemacht werden muss. Die Teilnehmer:innen werden sowohl durch die Spielkarten als auch durch eine:n Moderator:in unterstützt, die Fragen zur Methode des Context Mapping und zum Spiel beantworten kann. Die Durchführung des Spiels bedingt also mindestens eine Person mit Expertise in Domain-Driven Design und Context Mapping. Das Spiel bietet Raum für Kommunikation, Wissensaustausch, Aufbau von Methodenverständnis sowie für die gemeinschaftliche Definition von Abhängigkeiten der Bounded Contexts im eigenen Projektkontext. Bei regelmäßiger Anwendung wird dieses Verständnis gefestigt und inkrementell aufgebaut.

Spielanleitung des Context Mapping Game

Im Folgenden soll eine kurze Anleitung zum Context Mapping Game gegeben werden.

Ziel des Spiels

Das Ziel des Context Mapping Game ist es, als Team Abhängigkeiten zwischen Bounded Contexts zu ermitteln. Die Analyse eines Bounded Context in Bezug auf seine Abhängigkeiten stellt die Mission des Teams dar. Die Mission gilt als erfüllt, wenn Einigkeit hinsichtlich der Vollständigkeit der ermittelten und definierten Abhängigkeiten besteht und diese widerspruchsfrei als Context-Mapping-Pattern abgebildet sind. Die Abbildung erfolgt mit Hilfe der Spielkarten. In der Regel besteht ein Context Mapping Game aus mehreren Missionen, da komplexe Businessdomänen oft zahlreiche Abhängigkeiten aufweisen. Sobald alle Missionen abgeschlossen sind, endet das Spiel.

Spielvorbereitung

Die Vorbedingung für das Spielen des Context Mapping Game ist mindestens eine definierte Mission. Das bedeutet, dass mindestens eine Vision für einen Bounded Context existiert. Diese Vision umfasst Zweck, Verantwortlichkeiten und Existenzbegründung für den Bounded Context sowie die wichtigsten Geschäftsereignisse, Kommandos, Domänenobjekte und Geschäftsregeln. Die Beschreibung des Bounded Context mit den genannten Inhalten bildet das Spielfeld, auf dem die Karten abgelegt werden.

Eine empfehlenswerte Grundlage für das Spielfeld ist das Bounded Context Canvas der DDD Crew (Abb. 5). Ein Canvas ist ein visuelles Werkzeug, um komplexe Konzepte oder Probleme auf übersichtliche und strukturierte Weise darzustellen. Es bietet in der Regel klare Strukturen, die den Beteiligten dabei helfen, Informationen zu organisieren, Ideen zu generieren und Entscheidungen zu treffen. Das Bounded Context Canvas ist ein Instrument, um kollaborativ einen Bounded Context zu definieren und die wichtigsten fachlichen Designentscheidungen visuell zu dokumentieren [12].

Abb. 5: Das Bounded Context Canvas der DDD Crew [12]

Spielverlauf

Besteht das Spiel aus mehreren Missionen, was bedeutet, dass im Workshop mehrere Bounded Contexts betrachtet werden, wird im ersten Schritt die Mission ausgewählt. Jede Mission wird auf der Spieloberfläche ohne gelegte Spielkarten begonnen. Alle Spieler:innen haben ein Kartendeck in ihren Händen. Die Mission beginnt mit zehn Minuten Brainstorming von Abhängigkeiten (Dependency Storming). Im Anschluss werden gleiche Nennungen geclustert und die Abhängigkeiten in ein- bzw. ausgehende Abhängigkeiten unterteilt und als Sticky Notes auf das Spielfeld gelegt. Danach wird jede Abhängigkeit in einer Timebox von zehn Minuten diskutiert. Nach diesem Austausch legen alle Spieler:innen eine oder mehrere Spielkarten für den Upstream- und Downstream-Kontext auf das Spielfeld. Wie viele Spielkarten je Spieler:in gelegt werden, hängt vom ausgewählten Context-Mapping-Pattern ab. Weitere Details sind unter [13] beschrieben.

Wenn sich eine gemeinsame Basis mit Ausreißern ergibt, kann die Entscheidungsfindung durch die Erklärung der Ausreißer gestartet werden. Wenn das Ergebnis sehr unterschiedlich oder einheitlich ist, beginnt ein:e beliebige:r Spieler:in mit der Schilderung ihrer Sicht. Bei der aufkommenden Diskussion hat der/die Moderator:in die Aufgabe, die Diskussion zu leiten, sodass alle Spielerinnen zu Wort kommen und ein Commitment im Team hinsichtlich der final ausgewählten Spielkarten, d. h. der ausgewählten Context-Mapping-Patterns, erzielt wird. Ist es schwierig, ein Commitment zu erzielen, empfiehlt sich der Einsatz von Methoden für die Entscheidungsfindung, wie z. B. Dot-Voting oder Thumb-Voting. Für Thumb-Voting kann das Context Mapping Game mit unFix Decision Patterns [10] ergänzt werden. Dot-Voting ist sowohl vor Ort mit Stift oder Klebepunkten als auch remote auf einem Collaboration Board einfach durchführbar. Der Spielablauf ist ergänzend in Abbildung 6 dargestellt.

Abb. 6: Der Spielablauf des Context Mapping Game

Karten

Abbildung 7 zeigt die Domain-Driven Design Cards des Context Mapping Game in der Übersicht. Neben dem Namen des Context-Mapping-Patterns sind die wichtigsten Eigenschaften des Musters aufgeführt. Das fördert den Aufbau von Verständnis, analytischem Denken und Kreativität bei den Spieler:innen und ermöglicht auch Unerfahrenen die Teilnahme. Die Karten sind zum Download kostenlos unter [13] verfügbar.

Abb. 7: Die Spielkarten des Context Mapping Game

Fazit und Ausblick

Ein Blick auf die Rolle der Moderator:innen im Context Mapping Game ist eine nähere Betrachtung wert. Neben der Offenheit und intrinsischen Motivation des Teams ist der/die Moderator:in ein entscheidender Erfolgsfaktor. Nach unserer Erfahrung sind die Moderator:innen oft auch die Methodenexpert:innen für Domain-Driven Design und Context Mapping. Neben der Aufgabe, Fragen zur Methodik zu beantworten, ergeben sich beim Context Mapping Wechselwirkungen und implizite Abhängigkeiten zwischen Bounded Contexts, auf die spontan reagiert werden muss. Dies deckt das Spiel nicht ab.

Ein starkes Team findet sich in der Kombination aus Agile Coach und Domain-Driven Architect. Beide Rollenbilder fördern die Zusammenarbeit und besitzen die Fähigkeit, Workshops zu moderieren und zu gestalten. Der Agile Coach findet sich weiterhin im agilen Entwicklungsprozess wieder und nutzt dort zum Beispiel Backlog Refinement Cards [9], während der Domain-Driven Architect sich intensiv mit der Überführung der strategischen in die taktische Architektur beschäftigt und dafür das Architecture Game der Domain-Driven Design Cards als methodisches Hilfsmittel einsetzt. Auf Ebene der Organisationsentwicklung finden sich Agile Coach und Domain-Driven Architect auf Basis der Context Map wieder, um die fachliche und soziotechnische Architektur nach Domain-Driven Design in einen organisatorischen Rahmen wie Team Topologies oder SAFe zu integrieren, gestützt auf die Verwendung von unFix Cards [10].

Wir erleben Gamification als echten Unterstützer kollaborativer Projektarbeit, wenn die Ansätze auf die notwendige Offenheit treffen.

Links & Literatur

[1] Horowitz, Andreessen: „Why Software Is Eating the World“: https://a16z.com/why-software-is-eating-the-world

[2] Plöd, Michael: „Hands-on Domain-driven Design – by example“; Leanpub, 2020

[3] Lilienthal, Carola; Schwentner, Henning: „Domain-Driven Transformation“; dpunkt.verlag, 2023

[4] Khononov, Vlad: „Learning Domain-Driven Design“; O’Reilly, 2021

[5] Fowler, Martin: „BoundedContext“: https://martinfowler.com/bliki/BoundedContext.html

[6] DDD Crew: „Context Mapping“: https://github.com/ddd-crew/context-mapping

[7] Aprea, Carmen; Weckmüller, Heiko: „Gamification in der Qualifizierung und darüber hinaus: Alles nur ein Spiel?“: https://www.haufe.de/personal/neues-lernen/gamification-wie-effektiv-ist-das-spielerische-lernen_589614_534032.html

[8] Hombergs, Tom; Schiller, Thorben: „Gamification als Treiber von Codequalität“: https://www.heise.de/ratgeber/Gamification-als-Treiber-von-Codequalitaet-3759236.html?seite=all

[9] Hyoma, Nils: „Backlog Refinement Cards“: https://www.dependencypoker.com/backlog-refinement-cards

[10] unFix: „unFix Cards“: https://unfix.com/cards

[11] Harrer, Markus et al.: „Cards for Analyzing and Reflecting on Doomed Software“: https://cards42.org

[12] DDD Crew: „The Bounded Context Canvas“: https://github.com/ddd-crew/bounded-context-canvas

[13] Eschhold, Matthias: „Domain-driven Design Cards“: LINK